The main architectural novelty of High Speed Downlink Packet Access (HSDPA) is that the control of radio frame scheduling has been moved from Radio Network Controller (RNC) to Node Bs. While fix capacity, such as e.g. 64 kbps, may be reserved for traditional Dedicated Channel (DCH) traffic in the access network, for HSDPA, per flow bandwidth reservation is not efficient, because air interface throughput is much higher and fluctuates more. If bandwidth reservation is not used then a congestion situation may occur both in the transport network and in the air interface. In the current architecture, Transmission Control Protocol (TCP) cannot efficiently resolve a congestion situation in the access network, because lower layer retransmissions hide the congestion situations from TCP. Thus a flow control function has been introduced to control the data transfer between the RNC and Node B.
The Flow Control (FC) was designed to take only the transmission capabilities of the air interface into account and to limit the latency of layer 2 signaling. However, the increased air interface capacity did not always come with similarly increased Iub transport network capacity in practice. Iub is the interface between the Node B and an RNC. The cost of Iub/Iur transport links is still high and is not expected to decrease dramatically. It is a common scenario that the throughput is limited by the capacity available on the Iub/Iur Transport Network (TN) links and not by the capacity of the air interface. On these high cost links, it is important to maintain high efficiency. The transport network (TN) underneath the Frame Protocol may be realized e.g. as. a cell-switched Asynchronous Transfer Mode (ATM) network or as a packet-based IP network.
While on the air interface it is the task of the air interface scheduler to share the bandwidth among the flows, on the transport network it is the task of the flow control to provide fair bandwidth sharing among the flows of the same priority.
A rate-base flow control must be used, because the lack of sequence numbering and retransmission in the third Generation Partnership Project (3GPP) standard does not allow a window based flow control, like TCP. Note that while Radio Link Control (RLC) in the 3G system provides sequence numbering and retransmission functionality, the RLC protocol layer is not terminated in Node B, therefore cannot be used for flow control purposes. By rate based flow control is meant that the bitrate of a flow is regulated by the flow control algorithm.
To allow a simple and flexible flow control solution, a per-flow flow control algorithm may be defined for HSDPA.
The algorithm has an initial state, where the algorithm finds an initial capacity level fast. Slow start state is finished when the first congestion is detected. This state is called slow start.
After the first congestion is detected the allowed bitrate of a flow is reduced multiplicatively, e.g. by 50% if a congestion in the transport network is detected and increased linearly if no congestion is detected for a while, e.g. with 40 kbps/s increase rate. This behavior is according to the Additive Increase Multiplicative Decrease (AIMD) property and therefore the bandwidth share of the flows converges to the fair situation.
For the existing rate-based per-flow flow control solutions, two types of different transport network congestion events are defined. Hard congestion indicates serious congestion and results in 50% bitrate reduction, while soft congestion indicates that the transport network starts to be congested and results in 10% rate reduction. In the existing solution, lost or destroyed Iub/Iur High Speed Downlink Shared Channel (HS-DSCH) data frames and dynamic delay larger than 60 ms results in hard congestion, while dynamic delay in the range of 40-60 ms results in soft congestion.
The advantage of soft congestion is that it results in smaller rate decrease in case of moderate congestion. This smaller decrease means smaller oscillation for a rate based congestion control solutions and results in larger utilization of the transport network. However, the HSDPA traffic and peak HSDPA bitrates are expected to be increased and it is expected to result higher speed transport network. Typical transport network speed today is in the order of 1-4 Mbps and typical transport network buffer sizes are 212-1696 kbit. In case of Asynchronous Transfer Mode (ATM) transport network solution, while the transport network capacity is expected to increase significantly, the transport network buffer size is not configurable. With increased transport network capacity and the same buffer sizes, the maximum delay variation is expected to decrease significantly. E.g. the 212 kbit buffer results 212 ms long buffer in case of 1 Mbps transport network, 53 ms for 4 Mbps, and 21.2 ms for 10 Mbps. In this case, the maximum delay variation is decreased and with the current parameters, soft congestion cannot be detected. In this case the system will oscillate between 50% and 100% utilization, resulting 75% average utilization.
The lack of soft congestion thus causes several problems, e.g. 50% capacity decreases result in low utilization between 60 s and 120 s, when there are two users in the system.
One possible solution to the problem could be to tune the dynamic delay limits according to the actual transport network buffer sizes either off-line or on-line in the algorithm. The problem with such solution is that due to the potential delay variation introduced by higher priority traffic lower dynamic delay limits could result in false congestion detections and consequent underutilization.